home *** CD-ROM | disk | FTP | other *** search
/ AOL File Library: 2,801 to 2,900 / aol-file-protocol-4400-2801-to-2900.zip / AOLDLs / C++ Files Library / 3D & Offscreen for MacApp 3 / 3D & Offscreen Sample.sea / 3D & Offscreen Sample / Read Me < prev    next >
Text File  |  1993-07-02  |  6KB  |  157 lines
  1. Offscreen
  2.  
  3. This package contains three interesting classes. One, I hope will greatly help people in 
  4. the use of Offscreen GWorlds. These classes help do (almost) transparent offscreen manipulation
  5. in views for MacApp 3.0.1. All you do to get all drawing done in an offscreen GWorld
  6. is attach an adorner to any view (or multiple views) and everything is taken care of (almost).
  7.  
  8.  
  9. Enc.
  10.     TOffscreenAdorner.h
  11.     TOffscreenAdorner.cp
  12.     TOffscreenDrawEnvironment.h
  13.     TOffscreenDrawEnvironment.cp
  14.     
  15.  
  16. To use these classes, make the following calls:
  17.  
  18. From the any views DoPostCreate
  19.     TOffscreenAdorner* aOffscreenAdorner = new TOffscreenAdorner;
  20.     aOffscreenAdorner->IOffscreenAdorner('OffA', true, true );
  21.     this->AddAdorner (aOffscreenAdorner, kAdornFirst, false);
  22.  
  23. or anywhere else
  24.  
  25.     TOffscreenAdorner* aOffscreenAdorner = new TOffscreenAdorner;
  26.     aOffscreenAdorner->IOffscreenAdorner('OffA', true, true);
  27.     theView->AddAdorner (aOffscreenAdorner, kAdornFirst, false);
  28.  
  29.  
  30. Explanation of Classes:
  31.  
  32.     TOffscreenAdorner
  33.         This class, when attached to a view, will create and handle all
  34.         offscreen drawing. It does this by creating a TOffscreenDrawEnvironment
  35.         object and replaces the views current TDrawingEnvironment with
  36.         it. If for any reason offscreen drawing can't take place, then
  37.         normal drawing will occur. If RemoveFromView is called, the old 
  38.         TDrawingEnvironment is replaced and the view acts normally.
  39.         Due to flaws in MacApp 3, this adorner must be manually attached to
  40.         the view. The reason is that TAdornerList::AddAdorner does not call
  41.         anAdorner->AddedToView(this), which notifies the adorner which view it
  42.         is attached to. This is called in TView::AddAdorner, which properly calls
  43.         the method.
  44.  
  45.     TOffscreenDrawEnvironment
  46.         This Class is meant for transparent offscreen use in the MacApp 3
  47.         framework. It is a decendant of TDrawingEnvironment and is used as
  48.         one. However, due to several flaws in MacApp, neither this object nor
  49.         the Adorner we use can be used through ViewEdit (or Adlib).
  50.         THe reasons are that TDrawingEnvironment is created procedurally and
  51.         does not use the view creation. Thus even if a TOffscreenDrawEnvironment
  52.         is attatched, it will not be used. The way this class is loaded is by
  53.         attaching a TOffscreenAdorner to which ever view is using offscreen.
  54.         Under normal situations we would just add an adorner using Adlib 
  55.         (Viewedit does not allow custom adorner creation). However, due to
  56.         another flaw in MacApp, this is not possible. If you add an adorner to
  57.         a view (using Adlib), MacApp 3 does not call TAdorner::AddedToView,
  58.         while the View stream is being read in.
  59.         SOooo... to get around this problem, you must add the adorner manaully.
  60.  
  61.  
  62. Please note that these classes have only been partially tested, and may have bugs.
  63. If anyone see's any way to improve these classes, or any bugs, please report
  64. them to me, and I will maintain them. Also note that as yet these classes have not
  65. been tested with subviews (well they were, but they didn't work ). So, as yet don't
  66. add subviews to the view that does offscreen drawing.
  67.  
  68. Special thanks goes to Ken Ryall for his frameworks May 92 article.
  69. I had already developed similar classes, before I read his article, but was unable to
  70. solve a bug. His use of BeInPort solved it.
  71.  
  72. Bugs:
  73. While use of one (the global) or many Gworlds is fine in different windows, use of 2
  74. GWorlds in one window ( two views with the Offscreen attached) causes problems. I just
  75. discovered this problem.
  76. I use temp (multifinder) memory to allocate the GWorld. This can be problem for many
  77. programs, but I have had strange results using keepLocal as my flag. If anyone knows
  78. why this is so, please tell me.
  79.  
  80.  
  81.  
  82.  
  83. 3D
  84.  
  85. The second part of the package is an adaptation of VirtualSphere to MacApp 3.
  86. I claim no credit for this, in so far that I only adapted the code to MacApp 3.
  87.  
  88. These set of classes use the 3DGrafPort that has been in the Macs OS for a long time.
  89. Until recently, the machines where to slow to achive good speeds with the 3D manipuation.
  90. ( Trust me, I wrote some stuff way back on an SE and it was slow. ) These classes allow 
  91. use of the 3D port code by creating a TView subclass.
  92.  
  93. enc.
  94. T3DObjectView.cp
  95. T3DObjectView.h
  96. T3DTracker.cp
  97. T3DTracker.h
  98. T3DView.cp
  99. T3DView.h
  100. TVirtualSphere3DTracker.cp
  101. TVirtualSphere3DTracker.h
  102.  
  103. To use these classes:
  104. All you have to do is add a T3DView to a window. By itself, T3DView doesn't do much
  105. but you can subclass off it to allow all kinds of interesting things.
  106.  
  107. Also you must call in your main (although it really can be anywhere, as long as it is
  108. called before any 3D stuff is done).
  109. Port3DPtr    gThePort3DPtr;
  110. InitGrf3d (&gThePort3DPtr);
  111. and include 
  112. #ifndef        __GRAF3D__
  113. #include    <Graf3D.h>
  114. #endif
  115.  
  116.  
  117. Explanation of Classes:
  118.  
  119.     T3DView
  120.         This class is the root class for all 3D operations. It creates the 3D
  121.         Port and maintains it. I plan on enhancing this class for more robust
  122.         use.
  123.     
  124.     T3DObjectView
  125.         This class is the 3D workhorse. It's main function is to draw a polygon
  126.         based object to the port. This object can be almost anything, so long as 
  127.         it is defined as a PolygonNetData structure (look in ObjectData.h).
  128.         This class does the set up and drawing and handles the menus. If a mouse
  129.         is clicked on it, a T3DTracker subclass is created.
  130.     
  131.     T3DTracker
  132.         This class is an abstract class that handles 3D Trackers.
  133.         (I hope to add more functionaly to it later as I figure out new trackers)
  134.     
  135.     TVirtualSphere3DTracker
  136.         This is the subclass of T3DTracker that acts like the Virtual Sphere
  137.         example program on ETO 10. This Class holds several methods that 
  138.         determine the rotation for  sphere.
  139.         
  140. Special thanks goes to Michael Chen, most of the 3D code is his. I just adapted
  141. it to work with MacApp 3.
  142.  
  143. Bugs:
  144. As yet, I don't know why the matrix loses its vectors sometimes. When the vector
  145. becomes less then 0, the program normally would crash. So I destroy the matrix and start
  146. over. I know its a cheat, but it will take some time to solve this.
  147.  
  148. Special thanks goes to Michael Chen who wrote VirtualSphere (on ETO). Most of this 
  149. code is his, and I have only adapted it.
  150. Finally, feel free to use these classes to your hearts content. Share them, 
  151. and ALink me if you like them (or even if you don't).
  152.  
  153. Eric Hanig
  154. ALink: ABI.FC
  155. 800-874-9868 ex 8902
  156. AOL: Gimmel
  157.